METHODS AND ARRANGEMENTS FOR AUTOMATED CHANGE PLAN 



CONSTRUCTION AND IMPACT ANALYSIS 

Field of the Invention 

The present invention relates generally to operating distributed computing 
5 systems, and more particularly, to techniques for constructing and analyzing Change 
Plans. 

Background of the Invention ! i 

Change Management is central to ensuring the availability, reliability, and quality 
of information technology (IT) services. Change Management is the process by which 

10 Information Technology (IT) systems are modified to accommodate considerations such 
as software fixes, hardware upgrades and performance enhancements. Examples include 
changing the schema of a database table in a running application and installing a new 
release of a web application server in a multi-tiered eCommerce system. The importance 
of change management is underscored by recent studies showing that operator errors 

15 account for a large fraction of failures of Internet services. 

Central to Change Management is the Change Plan, the step-by-step procedure 
whereby a proposed change is implemented (e.g., Chou et al., Software - Practice and 
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Experience v 30 n 3 2000, pp. 175-197) by modifying the various artifacts of the system. 
Examples of artifacts include programs, database tables, and initialization files. This is 
illustrated by two services, Order Display and Buy Confirmation, that use the credit card 
transitions database table, CC_XACTS . When there is a Change Request to modify the 

5 schema of the database table (e.g., to accommodate new accounting procedures), the 
Change Request describes the end result of the change, such as having successfully 
modified the table schema. The Change Plan specifies times at which various tasks 
execute to transition from the current state of the system to its desired state. In this 
example, modifying the database schema requires installing a new version of the servlets 

10 Ordrdisp and Buyconf that implement these services. 

Fig. 1 displays a Change Plan for the Change Request in this example. Artifacts 
(either a database table or a servlet in this example) transition between different stages in 
their lifecycle: installable, executable, and running. For a service to be operational, all of 
its artifacts must be in the running state. To change an artifact, however, it must be 
15 transitioned first to the executable state and then to the installable state. The tasks in the 
plan are indicated by the lifecycle transition that they cause. The duration of the task is 
indicated by the length of its containing rectangle. For example, in the figure, Buyconf 
begins its transition from running to executable at time 0, and completes the transition at 
time 3. 
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The discussion will now focus on two parts of Change Management. The first is 
construction of the Change Plan. The Change Plan is critical to effective change 
management since it determines the state of artifacts and hence the impact on service 
delivery. As such, it is often desirable to provide impact analysis, whereby the effect of 
5 the Change Plan on services is determined. In particular, impact analysis indicates which 
artifacts and services are affected by a change. 

Some kinds of automation for Change Management are considered in the current 
state-of-the-art. For example, (1) Change Plan execution may be automated using 
workflow (e.g., Maurer et al., DEEE Internet Computing, May- June 2000, pp. 65-74), (2) 

10 the incorporation of software updates can be automated (e.g., US6385768, Ziebell, 
"System and method for incorporating changes as part of a software release"), and (3) 
versions and configurations can be managed for both persistent and transient objects 
(US5862386, Joseph et al., "Apparatus and method for providing a facility for managing 
versions and configurations of persistent and transient objects"). However, the 

15 construction of the Change Plan itself requires human intervention. 

The current state-of-the-art is also limited as to impact analysis. Today, the focus 
is on identifying the affected artifacts and services (e.g., US6601023, Deffler et al., 
"Method for impact analysis of a model"). It is much more valuable, however, to refer to 
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the duration of service outages caused by a change, or, more generally, to the cost of a 
change. These considerations are typically a function of the start and end time of service 
outages or degradations. For example, having an order entry application offline for two 
hours may not be a problem during a time when few people are shopping (e.g., Christmas 
5 Day) but may have a major impact at other times (e.g., the day before Christmas). 

Summary of the Invention 

In accordance with at least one presently preferred embodiment of the present 
invention, there is broadly contemplated a system and method for constructing and 
analyzing Change Plans. 

10 In summary, one aspect of the invention provides a system for automatic 

construction of a change plan, said system comprising: an arrangement for submitting a 
request for change to the system; an arrangement for constructing a task graph specifying 
the order in which tasks execute in compliance with data and temporal dependency 
constraints; and an arrangement for creating a change plan from the task graph. 

15 Another aspect of the present invention provides a method for automatic 

construction of a change plan, said method comprising the steps of: submitting a request 
for change to the system; constructing a task graph specifying the order in which tasks 
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execute in compliance with data and temporal dependency constraints; and creating a 
change plan from the task graph. 

An additional aspect of the present invention provides a program storage device 
readable by machine, tangibly embodying a program of instructions executable by the 
5 machine to perform method steps for automatic construction of a change plan, said 
method comprising the steps of: submitting a request for change to the system; 
constructing a task graph specifying the order in which tasks execute in compliance with 
data and temporal dependency constraints; and creating a change plan from the task 
graph. 

10 For a better understanding of the present invention, together with other and further 

features and advantages thereof, reference is made to the following description, taken in 
conjunction with the accompanying drawings, and the scope of the invention will be 
pointed out in the appended claims. 

Brief Description of the Drawings 

15 Figure 1 illustrates a Change Plan. 

Figure 2 is a block diagram of a system in accordance with the present invention. 
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Figure 3 is a flow chart of a method for Change Plan construction in accordance 
with the present invention. 

Figure 4 is a flow chart of a method for impact analysis in accordance with the 
present invention. 

5 Description of the Preferred Embodiments 

Several other copending and commonly owned U.S. patent applications, filed 
concurrently herewith, disclose various processes and arrangements whose details may, in 
the role of background information, help provide a better understanding of one or more of 
the embodiments disclosed and contemplated herein. Accordingly, those applications are 

10 hereby fully incorporated by reference as if set forth in their entirety herein, and are as 
follows (including the title and attorney docket number for each one): "Methods And 
Arrangements for Ordering Changes in Computing Systems" (Docket No. 
YOR920030547US1); and "Methods and Arrangements for Planning and Scheduling 
Change Management Requests in Computing Systems" (Docket No. 

15 YOR920030549US1). 

Referring now to Figure 2, the components of the Change Analysis System (100) 
and the interactions with human operators (102) and analysts (145) is shown. The 
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operator submits a request for change to the system. This is accepted by the Task Graph 
Builder (105) component (which is described in "Methods And Arrangements for 
Ordering Changes in Computing Systems" (Docket No. YOR920030547US1), infra). 
The Change Request is, in essence, a request for one or more packages. Thus, another 

5 input used by the Task Graph Builder are the descriptions of packages (1 10). Some of 
these packages may already be installed and hence the Task Graph Builder also takes as 
input Configuration Descriptions (1 15) so that it knows the current state of the system. 
The Task Graph Builder constructs a Task Graph (120) that specifies the order in which 
tasks execute in compliance of data and temporal dependency constraints. This is input 

10 to the Planner & Scheduler (125) (which is described in "Methods and Arrangements for 
Planning and Scheduling Change Management Requests in Computing Systems" (Docket 
No. YOR920030549US1), infra). A key input to the Planner & Scheduler are task 
descriptions (122) that specify, among other things, what lifecycle transitions are imposed 
on the artifacts of the system by the execution of the task. The output of the Planner & 

15 Scheduler is the Change Plan (130). This is used by the impact analyzer (140) to respond 
to requests by an analyst to analyze a service. Another input to the impact analyzer is 
service descriptions (135) that specify what artifacts and other services are used by a 
service being analyzed. 
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Referring now to Figure 3, a method in accordance with the present invention to 
construct a Change Plan is shown. In steps 210, 215, and 220, the Task Graph Builder 
inputs the Request for Change, Package Descriptions, and Configuration Descriptions. In 
225, the Task Graph Builder constructs the Task Graph. In 230 and 235, the Planner & 
5 Scheduler inputs the Task Graph and Task Descriptions to construct the Change Plan. 

Referring now to Figure 4, a method for impact analysis in accordance with the 
present invention is shown. In steps 310, 315, and 320, the Impact Analyzer inputs the 
service to analyze, the Change Plan, and the Service Descriptions. In 330, the Impact 
Analyzer computes 77, the first time that an artifact of the service to analyze transitions 

10 out of the running state. In 335, the Impact Analyzer computes 72, the completion time 
of the task in the Change Plan that results in having all artifacts of the service in the 
running state. In step 340, the Impact Analyzer reports the impact of the Change Plan on 
the service. This may use information that can be in the Service Description such as the 
number of requests for the service at different times of the day and the cost of a service 

15 outage. 

The Change Plan in Figure 1 will now be used to illustrate the operation of steps 
330 and 335 of the Impact Analyzer. Suppose that the Order Display service has two 
artifacts, the Ordrdisp serverlet and the CC_XACTS database table. Further, assume 
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that all artifacts of the change plan are initially in the running state. Then, 77=2 since the 
first task that causes an Ordrdisp artifact to transition from running to executable 
begins its execution at time 2. Further, T2=8 since the last Ordrdisp artifact to 
transition back to the executable state is completed at time 8. 

While the foregoing discussion of impact analysis focuses on the availability of a 
service, it is obvious to one versed in the art that this can be extended to the performance 
of a service. For example, many web services make use of tiers of servers, each of which 
contains multiple clones. A Change Plan applied to one clone does not make the service 
unavailable, but it does degrade performance. 

It is to be understood that the present invention, in accordance with at least one 
presently preferred embodiment, includes an arrangement for submitting a request for 
change to the system, an arrangement for constructing a task graph specifying the order in 
which tasks execute in compliance with data and temporal dependency constraints, and an 
arrangement for creating a change plan from the task graph. Together, these may be 
implemented on at least one general-purpose computer running suitable software 
programs. These may also be implemented on at least one Integrated Circuit or part of at 
least one Integrated Circuit. Thus, it is to be understood that the invention may be 
implemented in hardware, software, or a combination of both. 
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If not otherwise stated herein, it is to be assumed that all patents, patent 
applications, patent publications and other publications (including web-based 
publications) mentioned and cited herein are hereby fully incorporated by reference herein 
as if set forth in their entirety herein. 

5 Although illustrative embodiments of the present invention have been described 

with reference to the accompanying drawings, it is to be understood that the invention is 
not limited to those precise embodiments, and that various other changes and 
; modifications may be affected therein by one skilled in the art without departing from the 
scope or spirit of the invention. 
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